On the Temporality of Introducing Code Technical Debt

Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy work-load, tight delivery schedule, unawareness of good practices, etc. To shed light into the context that leads to technical debt accumulation, in this paper we investigate: (a) the temporality of code technical debt introduction in new methods, i.e., whether the introduction of technical debt is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of technical debt introduction and the development team’s workload in a given period. To answer these questions, we perform a case study on twenty-seven Apache projects, and inspect the number of Technical Debt Items introduced in 6-month sliding temporal windows. The results of the study suggest that: (a) overall, the number of Technical Debt Items introduced through new code is a stable metric, although it presents some spikes; and (b) the number of commits performed is not strongly correlated to the number of introduced Technical Debt Items

Change impact analysis: A systematic mapping study

Change Impact Analysis (CIA) is the process of exploring the tentative effects of a change in other parts of a system. CIA is considered beneficial in practice, since it reduces cost of maintenance and the risk of software development failures. In this paper, we present a systematic mapping study that covers a plethora of CIA methods (by exploring 111 papers), putting special emphasis on how the CIA phenomenon can be quantified: to be efficiently managed. The results of our study suggest that: (a) the practical benefits of CIA cover any type of maintenance request (e.g., feature additions, bug fixing) and can help in reducing relevant cost; (b) CIA quantification relies on four parameters (instability, amount of change, change proneness, and changeability), whose assessment is supported by various metrics and predictors; and (c) in this vast research field, there are still some viewpoints that remain unexplored (e.g., the negative consequences of highly change prone artifacts), whereas others are over-researched (e.g., quantification of instability based on metrics). Based on our results, we provide: (a) useful information for practitioners—i.e., the expected benefits of CIA, and a list of CIA-related metrics, emphasizing on the provision of a detailed interpretation of their relation to CIA; and (b) interesting future research directions—i.e., over- and under-researched sub-fields of CIA. © 2020 Elsevier Inc

Reusability Index: A Measure for Assessing Software Assets Reusability

© 2018, Springer International Publishing AG, part of Springer Nature. The reusability of assets is usually measured through reusability indices. However, these indices either do not synthesize their constituent metrics into an aggregate or they do not capture all facets of reusability, such as structural characteristics, external qualities, and their documentation. To alleviate these shortcomings, we introduce a reusability index (REI) as a synthesis of various software metrics that cover a number of related reusability aspects. Furthermore, we evaluate its ability to quantify reuse, by comparing it to existing indices through a case study on 15 reusable open-source assets (i.e., libraries and frameworks). The results of the study suggest that the proposed index presents the highest predictive and discriminative power, it is the most consistent in ranking reusable assets, and the most strongly correlated to their levels of reuse